昨天，你讓 AI PM Agent 自動把隱形工作排開，團隊終於有了即時、準確的工作全貌（Day 26）。
但今天早上，你遇到了全新的瓶頸——而這一次，瓶頸正是你自己。
你的 Inbox 裡躺著 34 個待審的 PR，Slack 裡則收到了 12 個審核請求。每個 PR 認真看完、理清邏輯需要 15 分鐘，這意味著你今天得花整整 8 小時只做程式碼審查。而到了明天，這個數字只會膨脹得更大。
早上十點，AI Team Lead 找到你：「有三個 PR 卡在你這裡兩天了，模型更新一直上不了線。」
你打開第一個 PR，程式碼寫得很漂亮，測試也都順利通過，但你心裡總有個聲音說「再仔細看看」——於是你把它扔進了「稍後審查」資料夾。第二個 PR 只是修改 Prompt 裡的錯字，你掃了一眼就點選 Approve 核准。第三個 PR 修改了資料庫連線參數，你眉頭一皺——這種修改以前可是出過大事故的（Day 2 震災災難），但你此時根本沒有時間去追蹤（Trace）它的影響範圍。你只能留言問：「這會影響到哪些服務？」然後開始漫長的等待回覆。
Data Lead 在 Slack 上 @ 你：「Schema 變更能今天審核通過嗎？我們明天要跑重要的對照組實驗。」你連看都還沒看，只能敷衍回覆：「晚點抽空看。」
Platform Lead 發來私訊：「K8s 配額（Quota）調整申請能幫忙加速嗎？我們已經在測試環境驗證過了。」你點開一看，發現這次變更動到了 12 個服務的配置，需要至少 30 分鐘才能確定沒問題。然而，你現在連 10 分鐘都擠不出來。
你突然痛苦地意識到：你成了團隊交付的瓶頸。
這並不是因為你不夠努力，而是變更的數量與複雜度，已經遠遠超越了任何單一肉身能審查的極限。
回想一下我們先前達成的里程碑：Day 9 安全防護左移（Security Shift-left）、Day 18 砍掉橡皮圖章、Day 19 透過 GitOps 擺脫上線災難——但如今，所有的 PR 依然全部死死地卡在「等待主管審查」這最後一關。
你可以選擇繼續咬牙用「我會儘快看」來死撐，但你非常清楚，這只是在延遲下一次系統爆炸的到來。
| 🔴 選項 A：繼續堅持人工審查每個變更，以確保上線品質 | 🔵 選項 B：引入 AI Reviewer 與政策即代碼自動化審查 |
|---|---|
| 短期效益：✓ 獲得「親手把關」的安全感，心理感覺踏實與踏實長期代價：✗ 審查瓶頸日益惡化，工程師為趕時程開始暗中走捷徑✗ 真正高風險變更被淹沒在海量瑣碎變更中，極易漏看結果：✗ 審查速度越來越慢，交付品質不升反降 | 短期代價：✗ 需要建立與改寫審查 Policy 規則，花時間適應人機協作長期效益：✓ 審查速度與標準高度一致，低風險變更秒級自動核准✓ 專家時間得以釋放，專注於 AI 標紅的少數高風險例外結果：✓ 速度與品質兼顧，人機分工更明確，責任更清晰 |
你盯著那 34 個待審的 PR。
如果選擇選項 A，你非常清楚下場：明天會變成 40 個，後天變成 50 個，最後你要麼累死，要麼開始放棄原則「閉眼點通過」——那你就變成了自己最討厭的那枚橡皮圖章。
如果選擇選項 B，你必須說服自己和團隊：AI 在規則檢查上，能做到我們人類做不到的事——它更快、更一致，而且永遠不會疲倦。
先別往下捲。如果是你，你敢讓 AI 接手你的日常審查工作嗎？
正確答案是 選項 B。
這可能是最違反直覺的決定——「安全把關」向來是管理者的責任，怎麼能輕易交給 AI？
關鍵在於區分兩種截然不同的審查維度：
前者 AI 做得比人類好得多——它從不疲倦、絕無遺漏，且標準高度一致。而後者則只有人類能做——因為這需要理解商業脈絡、團隊目標以及歷史背景決策。
這就是 政策即代碼（Policy as Code） + AI Reviewer 的核心實踐：
審查職責並非被外包給了 AI，而是被進行了合理的分層過濾：
你的責任並沒有減少，相反地，它變得前所未有的清晰——你不再需要審查所有的日常 PR，而只需專注於 AI 判斷需要你做出決策的那些關鍵變更。
你找來 Platform Lead 與 AI Lead 說明：「我們導入 AI Reviewer，不是為了逃避把關的責任，而是為了讓審查變得更加科學與高效。」
起初他們半信半疑。你現場點開一個 Demo PR——正是剛才那個 K8s memory quota 的調整變更。
在傳統流程下，你起碼要花 30 分鐘：看代碼 Diff、去雲端後台查詢會影響哪些 Pod、估算剩餘的 Quota、擔心會不會 OOM，最後還要私訊工程師「這你在 staging 測過了嗎？」
現在，AI Reviewer 僅花費 3 分鐘便自動在 PR 下方產出了一份風險報告：
graph TD
A[工程師提交 PR:<br/>調整 memory quota 2GB->1.5GB] --> B[AI Reviewer 自動掃描]
B --> C[Policy 檢查:<br/>是否符合 resource policy]
B --> D[影響分析:<br/>會影響哪些服務]
B --> E[Staging 測試:<br/>自動 apply 並監控]
B --> F[歷史對比:<br/>類似變更的結果]
C --> G[產出風險報告]
D --> G
E --> G
F --> G
G --> H{風險等級}
H -->|LOW| I[自動標記<br/>可 merge]
H -->|MEDIUM| J[建議人工確認]
H -->|HIGH| K[阻擋 merge<br/>要求修正]
model-server, feature-extractor, cache-warmer）。model-server 達 1.2\text{ GB}（峰值 1.6\text{ GB}），其他兩項服務各為 0.4\text{ GB} / 0.3\text{ GB}。model-server 峰值用量 1.6\text{ GB} 已超出新設定的 1.5\text{ GB} 限制；若三項服務同時達到峰值負載，整體用量將超出分配（2.5\text{ GB} > 1.5\text{ GB}）；Staging 環境自動化負載測試跑了 18 分鐘後引發 OOM Killed。你看完報告只花了 3 分鐘，隨即拍板決策：「採納建議，先改成調降至 1.8\text{ GB}，並在 Description 中補上後續的觀察計畫。」
工程師修改 PR，AI 重新掃描後判定為 LOW 低風險，你隨手點選核准並進行 Merge，整個流程宣告完成。
原本需要拉扯 30 分鐘以上的溝通，被壓縮到了 5 分鐘內，且決策品質大幅提升——因為 AI 為你提供了詳盡的數據、歷史和實測結果，而不是憑直覺猜測。
AI Lead 驚奇地問：「這個 Policy 檢查在程式碼裡是怎麼實現的？」
你向他展示了他們之前踩坑的資料庫 Timeout 設定（類似 Day 2 導致系統雪崩的參數修改）。
在沒有 Policy as Code 的過去，這種看似無害的改動很容易就被隨意批准，直到半夜資料庫被連線卡死時才被動發現。
但現在，你們將「資料庫連線 Timeout 政策」直接寫成了可執行的代碼：
# policies/database_timeout_policy.py
def check_db_timeout_change(change):
"""
Policy: Production 資料庫 timeout 不得低於 30 秒
Exception: Cache 類資料庫可低至 5 秒
"""
if change.environment == "production":
if change.service_type != "cache":
if change.new_timeout < 30:
return {
"result": "BLOCK",
"reason": "Production DB timeout 不得低於 30 秒",
"reference": "https://wiki/policies/db-timeout"
}
# 檢查是否有高 latency 的查詢會受影響
affected_queries = analyze_queries(change.db_name)
slow_queries = [q for q in affected_queries if q.avg_time > change.new_timeout]
if slow_queries:
return {
"result": "WARN",
"reason": f"發現 {len(slow_queries)} 個查詢平均執行時間超過新 timeout",
"queries": slow_queries,
"suggest": "建議先優化這些查詢，或提高 timeout"
}
return {"result": "PASS"}
當有工程師試圖提交 PR 將資料庫 Timeout 縮短為 5 秒時，自動化 Policy 檢測會立即觸發：偵測到非 Cache 類資料庫 ➔ 自動阻擋 Merge，並在 PR 下方自動留言警告與政策文檔連結。
工程師看到警告後恍然大悟，主動將參數修改回 30 秒，重新提交後順利 Pass 通過。
Platform Lead 興奮得直點頭：「所以，我們以後只要把團隊踩過的所有坑都寫成 Policy 代碼，下一個同仁就絕對不可能再犯同樣的錯誤了？」
你笑著點頭：「沒錯。而且因為 Policy 本身就是代碼，它同樣可以進行版本控制與 Code Review。如果規則太嚴苛，我們就修改 Policy 代碼本身，而不是靠嘴巴去『糾正大家的壞習慣』。」
我們來看一個 50 人工程團隊、每週平均產生 120 個 PR 的真實轉型指標。
三個月後，團隊的運作指標迎來了質的飛躍：
AI 從來不是為了完全取代人工審查，而是為了幫人類把關，過濾掉雜訊，好讓珍貴的人腦專注於真正需要它的地方。
Data Lead 聽完，有些擔憂地問：「如果 AI 判定為 LOW 並自動放行，但最後判定錯誤出了線上事故呢？這個責任由誰來擔？」
你平靜地回答：「AI 不會消滅我們的管理責任，它只是擴大了我們的管理能力。最終的架構責任依然在我們——但我們的工作模式改變了：過去我們強求自己審查每一個 PR，結果是精力被稀釋、看漏了一堆 Bug。而現在，我們的工作是維護這個『審查系統』的健康運作：制定 Policy 規則、調校 AI 分類閥值，並深度審查 AI 標記為 HIGH 的高風險例外。同時，AI 標記為 HIGH 的 PR，系統強制鎖定，必須由人工 Approve 才能進行 Merge。」
這不是「讓 AI 做決策」，而是「讓 AI 做高級過濾」——幫你揪出那最危險的 4%，把好鋼用在刀口上。
AI Lead 點點頭：「所以這並不是因為我們『盲目信任 AI 永遠不會犯錯』，而是我們『信任 AI 能幫我們過濾出最需要人腦判斷的異常』？」
「完全正確。AI 只是我們的戰術助手，它無法理解長遠的架構 Trade-off。但『在超大規模下毫無疲態地執行規則、分析服務相依性』，這是人類肉身的弱點，卻正是 AI 最擅長的事。人機協同，才是我們走出審查地獄的唯一道路。」
「讓 AI 負責審查它最擅長的硬性規則，讓人類專注審查只有人腦能權衡的商業意圖。」
你們團隊目前的代碼與變更審查，是在「真的落實把關」，還是因為時間不夠，早已淪為了流於形式的「假裝把關」？
如果每個 PR 在提交的第一時間，都有 AI 自動執行完 Policy、跑完影響範圍分析並比對過歷史事故，你們的審查效率與上線品質會不會比現在更好？
如果答案是肯定的，那你就知道你的團隊下一個該自動化的方向在哪裡了。
明天，我們要面對一個更深層的治理挑戰：既然 AI Agent 已經開始在各個環節幫你處理實質工作——彙整工作、審查代碼、回答新人技術問題——那它算不算是你們團隊的一名「虛擬成員」？
如果是，它出了錯該由誰負責？它的績效又該如何去衡量？
當我們需要開始為 AI Agent 制定績效考核時，組織管理將進入一個全新的維度。
Day 28 見。
iThome鐵人賽
看影片追技術